1. Field of the Invention
The present invention relates to communication networks and, more particularly, to a method and apparatus for allocating processing capacity of system processing units in an extranet gateway.
2. Description of the Related Art
Data communication networks may include various computers, servers, nodes, routers, switches, hubs, proxies, and other devices coupled to and configured to pass data to one another. These devices will be referred to herein as “network elements.” Data is communicated through the data communication network by passing protocol data units, such as packets, frames, cells, or segments, between the network elements by utilizing one or more communication links between the devices. A particular packet may be handled by multiple network elements and cross multiple communication links as it travels between its source and its destination over the network.
The various network elements on the communication network communicate with each other using predefined sets of rules, referred to herein as protocols. Different protocols are used to govern different aspects of the communication, such as how signals should be formed for transmission between network elements, various aspects of what the protocol data units should look like, how protocol data units should be handled or routed through the network by the network elements, and how information such as routing information should be exchanged between the network elements.
A Virtual Private Network (VPN) may be formed by securing communications between two or more networks or network elements to form a VPN tunnel, such as by encrypting or encapsulating transmissions between the networks or network elements. Using VPN tunnels enables information to be exchanged securely between geographically dispersed sites without requiring the network in between those sites to be otherwise secure. VPN tunnels thus may be used to secure traffic, for example, across a public network such as the Internet. VPN tunnels may be used in many contexts, however, and securing traffic on the Internet is merely one example of a use for VPN tunnels.
There are currently two commonly utilized methods of establishing VPN tunnels on a network. The first model is described in Internet Engineering Task Force (IETF) Request For Comments (RFC) 2547, the content of which is hereby incorporated herein by reference. RFC 2547 describes a VPN architecture in which MultiProtocol Label Switching (MPLS)—based tunnels are used to forward packets over the network backbone. One or more instances of Border Gateway Protocol (BGP) are used to distribute routes over the backbone for the VPNs provisioned through a particular Provider Edge network element (PE). Routing information for each VPN serviced by a PE is stored in a separate VPN routing and forwarding table (VRF) or a distinguishable area of the PE's common VRF.
A second model for establishing VPN tunnels through a network is based on the concept of a Virtual Router (VR). A virtual router is a software construct in a physical router that has all the attributes of a physical router, but which shares processor time, switch plane resources, and other physical resources of the physical router. Because the virtual router is logically separate from other virtual routers, it has its own routing space, its own policy information, and is able to be provisioned much the same as any other router on the network.
A given VPN site may connect to multiple VPN tunnels through the external network. For example, a VPN site may wish to establish tunnels to branch offices and may wish to establish client tunnels with individuals or other networks to allow employees, suppliers, and/or customers to access resources on the network associated with the VPN site. In this instance, the VPN site may participate simultaneously on hundreds or thousands of branch office and client VPN tunnels. One or more network elements, such as extranet gateways, may interface these VPN tunnels to the VPN site.
As networks have increased in size and sophistication, the number of tunnels to be supported to a given VPN site has increased dramatically, which places a large burden on the CPU configured to implement the VPN tunnels on the extranet gateway. For example, a given extranet gateway may be required to handle hundreds or thousands of VPN tunnels simultaneously. In a VR-based VPN environment, CPU resources may be required to enable the extranet gateway to function as a virtual router assigned to that VPN. In a MPLS-based VPN, CPU resources may be required to enable the extranet gateway to perform encapsulation and de-encapsulation of VPN traffic into MPLS packets. Additionally, traffic on VPN tunnels is routinely encrypted to provide an added measure of security to the traffic passing on the tunnels. Since encryption operations require considerable CPU resources, encrypting traffic on a VPN tunnel increases the amount of processing time required to handle the protocol data units on that given tunnel.
One way to enable an extranet gateway to handle larger numbers of VPN tunnels is to provide multiple CPUs in the extranet gateway and to include hardware accelerators, such as encryption accelerators, in the extranet gateway. CPUs and hardware accelerators will be referred to herein as system processing units (SPUs). Generally, in modern large extranet gateway network elements, several system processing units, such as one or more CPUs and one or more encryption accelerators, will be used to handle the load placed on the extranet gateway by the VPN tunnels. While this may provide the extranet gateway with sufficient processing power to handle the number of VPN tunnels required to be provisioned through the extranet gateway, an issue arises as to how to distribute the VPN tunnels to the several system processing units in the extranet gateway.
One way to distribute the load between the several system processing units that has been used in the past is to assign VPN tunnels in a round robin fashion, such that a first of the system processing units is assigned a first tunnel, the next SPU is assigned the next, and so-on. Additionally, attempts have been made to use a modified round-robin approach, for example by assigning twice as many tunnels to the accelerators as to the CPUs. Unfortunately, this proves to be unworkable due to the random nature with which tunnels are brought up and taken down, the blind nature of tunnel assignment, and the different processing capabilities of the different system processing units. Additionally, where one of the SPUs needed to be replaced, possibly with a different type of SPU, the assignment process needed to be reconfigured.